Service logic execution environment (SLEE) that is running on a device, supporting a plurality of services and that is compliant with a telecommunications computing standard for SLEES

ABSTRACT

The present invention relates to the field of software-based services in communication networks. More particularly, it includes systems and methods for maintaining and utilizing routing data to handle event notifications generated by call handling in a service logic execution environment. Particular aspects of the present invention are described in the claims, specification and drawings.

RELATED APPLICATIONS

This application is the National Stage filing of PCT Application No.PCT/US02/28482, filed 6 Sep. 2002, entitled Converged Service DataAutomation and claims the benefit of U.S. Provisional Application No.60/318,123, filed 7 Sep. 2001. entitled Converged Service DataAutomation.

This application is related to the commonly owned PCT Application No.PCT/US02/28591, filed 6 Sep. 2002, entitled SLEE Service Convergence andRouting and incorporated herein by reference, which claims the benefitof commonly owned U.S. Provisional Application No. 60/318,163, filed 7Sep. 2001, entitled SLEE Service Convergence and also incorporatedherein by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

REFERENCE TO COMPUTER PROGRAM LISTING APPENDIX

A computer program listing appendix comprising duplicate copies of acompact disc, named “TTel,” accompanies this application and isincorporated by reference. The computer program listing appendixincludes the following files:

FindMeDeployment.java   986 bytes created Sep. 3, 2002 (File containinggenerated Service Deployment call back class and method code.)FindMeManagement.java   885 bytes created Sep. 5, 2002 (File containinggenerated Service Management call back class and method code.)FindMeSbb.java  4,053 bytes created Sep. 5, 2002 (File containinggenerated stubs for the class containing the event handlers that servicelogic can be added to.) FindmeSbbProfileData.java  2,186 bytes createdSep. 5, 2002 (File containing generated code to access Service scopedata). FindmeSubscriberProfileData.java  3,691 bytes created Sep. 5,2002 (File containing generated code to access Subscriber scope data).JSDL.tcl 16,689 bytes created Sep. 3, 2002 (File containing utility codefor code generation). JSDL.xml  2,352 bytes created Sep. 3, 2002 (Filecontaining the service descriptor for standard JAIN SLEE servicefeatures). PhoneMap.java 13,459 bytes created Sep. 5, 2002 (Filecontaining generated code that models Subscriber profile data as Javaobjects). TestProperty1Property.java  3,556 bytes created Sep. 5, 2002(File containing generated code that models Subscriber profile data asJava objects). TSDL.tcl  6,839 bytes created Sep. 3, 2002 (Filecontaining utility code for code generation). TSDL.xml  1,467 bytescreated Sep. 3, 2002 (File containing the service descriptor forTrueConverge extended SLEE service features). TSDL.xsd 17,654 bytescreated Sep. 5, 2002 (XML schema defining the grammar for TSDL.xml,which is the file that contains the service descriptor for TrueConverge,extended SLEE service features).

BACKGROUND OF THE INVENTION

The present invention relates to the field of software-based services incommunication networks. More particularly, it includes systems andmethods for maintaining and utilizing routing data to handle eventnotifications generated by call handling in a service logic executionenvironment.

A service is a software application that is installed in a communicationnetwork to provide value added functions to subscribers. Subscribers areusers of the communication network who subscribe to the services.Services control the network to perform value-added functions forsubscribers based on provisioned data and network conditions. Serviceinstance is a single run time instance of the service that provides theservice functions to a subscriber. A service may include one or moreservice instances, which may be operating in different modes to handledifferent phases of providing the service. Service Logic ExecutionEnvironment (SLEE) is the run time environment in which a serviceexecutes. A SLEE is a new approach to the long-standing issue of how tosupplement switches with intelligent capabilities. Sun Microsystems,Inc. has sponsored development of telecommunications computingstandards, so that service logic execution environments will have open,non-proprietary architectures. The so-called JAIN SLEE standard reachedthe stage of public comment on 12 Aug. 2002, having gone through draftsprior to that. A SLEE is intended to support multiple services andaccept software written by multiple vendors in compliance with one ormore telecommunications computing standards.

The JAIN SLEE standard leaves much to be filled in by the servicedeveloper. JAIN SLEE is essentially an application program interface(API) specification that does not specify the internal details ofimplementing services. JAIN SLEE specification is very generic in thedefinition of service and subscriber data. This provides a lot offlexibility but comes with a cost, as it places the burden on theservice developers to provide the necessary Management interfaces. Thestandard does not provide any mechanism for the service developer todefine the data schema for the service and subscriber data. Nor does itdefine any mechanism to provide sophisticated data provisioning andmanagement. The complementary Java Management (JMX) standard is stillevolving. In JAIN SLEE, Event Triggering is the primary mechanism toinvoke services, which limits efficient use of the Services by otherapplications and clients that are not based on an event model, such asweb based provisioning and statusing interfaces.

Traditionally, both before JAIN SLEE and even now, as the first publiccomment draft is being circulated, service execution platforms are beingbuilt to serve a single function on a proprietary platform, to deliver asingle event or sequence the events from a single source to one serviceinstance. Traditional platforms have associated a call or a sequence ofevents to a service instance and delivered all the events of that callor sequence to the same service instance. These special purposeplatforms have worked well for stable services that support events froma single network. But special purpose platforms have proven cumbersomeand expensive to modify and difficult for a support staff to integrateand maintain.

Services include two important components—service logic and servicedata. Service data may have both service scope data, which is the datathat is common across the service, and subscriber scope data, which thedata specific to a subscriber related to the service. A serviceexecution environment like a SLEE benefits from support for persistingthe data, provisioning the data, and exposing the data to servicesduring runtime. Existing proprietary platforms support the service databy typically defining it using some method specific to the underlyingdatabase system of the platform—a proprietary language or a more genericlanguage like SQL. Service developers typically also have to developinterfaces to provision this data along with the services. Duringexecution, the services access the data using some proprietaryprogramming interface or a more generic interface like JDBC. Theproblems with these platforms are multifold, including lack ofcompliance with JAIN SLEE or any similar telecommunications computingstandard. First, the service developers need to understand the platformdesign to be able to develop data provisioning interfaces and have tomanage their own data persistence by accessing and updating it usingsome programming interface. Second, the service data definition onproprietary platforms is so closely tied to the platform data that theplatform has to restrict the power/functionality of service datadefinition, or require it to be statically defined before platforminstallation, so the proper analysis of its impact on the platform andother service on the platform can be done. This makes it hard todynamically deploy a new service. Third, the service developers have toconcern themselves with the underlying details of the platform databaseand user interfaces rather than just focusing on what the service does.

Services are typically triggered by events, requests or messages (weshall use the terms event and event notification to refer to all ofthem) originating in the call processing system and other externalsystems, and some of the service execution platform provided services aswell. Addresses are the identifiers that typically identify thesubscribers associated with the events by points of call origination,destination or both. Addresses also may identify participants in aservice other than the subscriber.

With the development and improved capabilities of wirelesscommunications and the Internet, more and more services are beingoffered on multiple networks. For example, a simple voice service couldserve subscribers whose calls originate from a land based telephonenetwork, a wireless telephone network, and an the Internet connection.Similarly, a text-based chat room could serve subscribers calling infrom a public telephone, using a web browser over the internet,sending/receiving Short Messages from a wireless phone, andsending/receiving email from a distribution list. Enhanced services forsubscribers from multiple networks are so-called converged services.

Accordingly, there is an opportunity to provide software componentscompliant with a telecommunications computing standard for a servicelogic execution environment, such as the emerging JAIN SLEE standard ora subsequent standard. In this new environment designed to supportmultiple types of service and multiple vendors, many components need tobe developed to support development and execution of new services. Forinstance, there is an opportunity to provide methods and devices thatassist service developers in specifying their service definition andrequirements for the service data. In addition, it is useful to supportservices with component operable in the service logic executionenvironment that support data persistence and access, with minimaldevelopment effort by service developer.

SUMMARY OF THE INVENTION

The present invention relates to the field of software-based services incommunication networks. More particularly, it includes systems andmethods for maintaining and utilizing routing data to handle eventnotifications generated by call handling in a service logic executionenvironment. Particular aspects of the present invention are describedin the claims, specification and drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an object view of the TSDL schema

FIGS. 2A and 2B show user interfaces generated for subscriber scope dataaccess.

FIG. 3 is a tree that organizes information collected through the userinterface.

FIG. 4 is a graphical user interface that collects service informationcategorized as basic information, other information and a description.

FIG. 5 is a graphical user interface that collects identifiers ofservice classes.

FIGS. 6 and 7 are graphical user interfaces that collect eventinformation.

FIG. 7 is a graphical user interface that collects event information.

FIG. 8 is a graphical user interface that allows identification of usageinformation and resource information.

FIG. 9 is a graphical user interface that collects JNDI EnvironmentEntries.

FIG. 10 is a graphical user interface that collects web applicationrelated data.

FIG. 11 is a graphical user interface for specifying enumerations.

FIG. 12 is a graphical user interface that collects service mode andadds lookup information.

FIG. 13 is a graphical user interface to a Gsi Address lookup table.

FIG. 14 is an Address Lookup interface.

FIG. 15 is an interface for selecting an address type.

FIG. 16 is a graphical user interface for specification of serviceproperties.

FIG. 17 is a graphical user interface for adding an index, to enhancesystem performance.

FIGS. 18 and 19 illustrate two out of three steps for creating a foreignkey.

FIG. 20 is a graphical interface for defining a service table.

FIG. 21 is a graphical interface for defining attribute details.

FIG. 22 is an interface for selecting a rule type.

FIG. 23 allows definition of a rule.

FIG. 24 is an interface for entry of foreign keys.

FIG. 25 is a graphical interface for a user to specify index details.

FIG. 26 is a pull-down menu that allows a developer to invoke aspects ofautomatic code generation.

FIG. 27 illustrates a converged network.

DETAILED DESCRIPTION

The following detailed description is made with reference to thefigures. Preferred embodiments are described to illustrate the presentinvention, not to limit its scope, which is defined by the claims. Thoseof ordinary skill in the art will recognize a variety of equivalentvariations on the description that follows.

Service developers can define service data information in XML servicedeployment descriptors using the TrueConverge™ Service DescriptionLanguage (TSDL). Service deployment descriptors are XML files created bythe service developers to define various service related data that canbe used for code generation and to control deployment of the service. Inone embodiment, a SLEE supports two different descriptors. Onedescription is a required JSDL (JAIN SLEE Service Description Language)descriptor compliant with the definition of the service DTD in the JAINSLEE specification. By compliant, we mean compatible with draft orpublic comment versions of the JAIN SLEE standard or subsequent versionsor adaptations of the standard. Compatibility, in this sense, does notrequire a complete implementation of the standard. One of skill in theart will recognize that the present invention applies as well tosubsequently-developed telecommunications computing standards that maysupplement or supplant JAIN SLEE. The other descriptor is an optionalTSDL file containing information that extends JAIN SLEE for service datadefinition, provisioning, convergence control, routing,internationalisation/localization, and component packaging. An XMLschema for TSDL is included in the CDRom Appendix file TSDL.xsd. In theservice descriptor definition phase in addition to the eventdescription, the user describes the data model, deployment propertiesetc. in the XML format using the JSDL and TSDL, optionally using agraphical interface. While the JAIN SLEE specification defines theservice descriptor using an XML DTD (Document Type Description) format,it also can be defined using an XSD (XML Schema Definition) to provideadditional checks and validation. This difference in XML schemadefinition languages should be transparent to the service developers.

The information that can be specified in TSDL includes: (1) servicename, version, and creation date; (2) basic data entities called serviceattributes; and (3) for each service attribute: (a) whether it is arequired attribute; (b) whether it is automatically generated; (c) adefault value of the attribute; (d) a type for the attribute, from apredefined set of types; (e) valid values of the attribute; and (f) userinterface properties for display and searchability. The informationfurther includes: (4) two types of service data entities both composedof service attributes: (a) service properties, which are complexentities made of 1 or more service attributes; and (b) service tables,which are complex entities containing multiple records, where eachrecord is made of 1 or more service attributes. Service properties mayinclude a (a)(i) scope, such as a subscriber scope or service scope;(ii) optional foreign keys that are composed of 1 or more attributes ofthe property; (iii) access modes for data to read, write, update, deletefor service, subscriber and administrator levels; and (iv) optionalvalidation rules. Service tables may include a (b)(i) scope of thetable, such as a subscriber scope or service global scope; (ii) aservice key, which is composed of 1 or more attributes of the record;(iii) optional foreign keys, which are also composed of 1 or moreattributes of the record; (iv) an optional container table which is aparent of the service table; (v) optional indexes used to guide theplatform for storage and retrieval efficiencies; (vi) access modes fordata to read, write, update, delete for service, subscriber andadministrator levels; (vii) optional validation rules for data.Validation rules for service properties or service tables may includedata range, length and regular expression based rules, value andexistence based rules, and property, table, and record level rules,including inter entity and intra-entity validations.

Service developers further can use TSDL to defineinternationalization/localization options, through the definition of aninternationalization file that contains data to internationalize userinterface, display items and error messages. Custom options supportedinclude validation by callback methods, to allow service developers toperform their own validation, and adoption of user interface, bothautomatically generated and user supplied optional user interfacecomponents, to allow service developers to provide their own userinterface. The TSDL schema in TSDL.xsd illustrates how the presentinvention can support these service development features. Correspondingto the schema, FIG. 1 provides an object-oriented view of aspects ofTSDL. Entity TSDL 101 includes basic information such as service name,version, creation date and an internationalization file string. Aplurality of service properties 111 may be associated with TSDL 101. Aservice property may have a name and an enumerated scope. A plurality ofservice tables 112 also may be associated with TSDL 101. A service tablemay have a name and an enumerated scope. A plurality of serviceattributes 121 may be associated with either a service property 111 or aservice table 112. A service attribute may have a name, an enumeratedtype, an access mode and a changeable status. It also may have a maximumlength and a default value. A plurality of service table keys 122 may beassociated with a service table 112. A plurality of service tableindexes 123 also may be associated with a service table 112.

In operation, the SLEE platform, here inclusive of development softwaresupporting the SLEE run-time environment, parses the provided serviceTSDL information, validates it against the TSDL definition, and buildsservice meta data. In one embodiment, this service meta data includes aJava representation of the service description information.

During service development, the SLEE platform uses the service metadata, and predefined templates to generate programming objects in alanguage such as Java or C++ that correspond to the defined serviceproperties and service tables. These objects contain access methods thatcan be directly used by service developers to access and persist theservice data in a database, without having to use any database specificinterfaces.

During service installation, the SLEE platform (including developmentsoftware) can use the service meta data to construct a physical datamodel, supporting the service. It maps the service tables and propertiesinto tables in a database, preferably a relational database. It maps theattributes into column of the database tables, and maps the attributetypes into the column types. It maps the table keys, foreign keys,indexes, container tables into appropriate database entities. It maygenerate supporting database entities like views, indexes, sequences,stored procedure to support things like access, auto generation andvalidation. It may generate data definition language (e.g., SQL) for theunderlying database management system. It may use service priority andother service related information to allocate appropriate resources forservice related entities. It may create and initialize all the generateddatabase entities by executing the Data Definition Language through anunderlying database system.

After service installation, the SLEE platform uses the metadata andtemplates corresponding to different network types, such as HTML, WML,VXML templates, to generate components such as: HTML-based Java serverpages (JSPs) that provide user interfaces for the service administratorsto provision and manage the service data and HTML, WML and/or VXML basedJava server pages that provide user interfaces for direct provisioningof subscriber scope service data by the subscriber. These Java serverpages generate the appropriate interfaces in the respective markuplanguage during actual interaction with the users. Other technologiesfor generating pages, such as XSLT or even static pages, canalternatively be used.

A simple example is useful, before an extended description. Consider asimple service called “FindMe”, which enables a subscriber to specify alist of telephone numbers (also referred to as addresses) and avoicemail number. The service implements the following logic: If any ofthe numbers belonging to the subscriber receive a call, all the numbersring until one of them is answered. If the there is no answer on anynumbers for a certain period of time, the call is directed to the voicemail. Aspects of the present invention collect a service datadescription, and then generate Java objects, physical data model, andprovisioning interfaces. For this example, the underlying networkprovides a JCC API for the service. To be able to implement the behaviordescribed, the FindMe service needs to be notified when there is anincoming call to a subscribed address, when the subscriber answers oneof the configured addresses, and when one of the configured addresses isbusy.

In a JAIN SLEE embodiment, the following FindMe events corresponding toJCC events: JccConnectionEvent.CONNECTION_ALERTING—This is the initialevent on which the service will be invoked. This event will invoke theFindMe service when the subscriber's address is being notified of anincoming call. JccConnectionEvent.CONNECTION_CONNECTED—This eventindicates that the subscriber has answered on the connection on which itoccurs. JccConnectionEvent.CONNECTION_FAILED—This event is receivedindicating a busy connection, if any of the connections are busy.

The FindMe service, in this example, defines event handlers for thesethree events. onConnectionAlerting()—Handles the CONNECTION_ALERTINGevent, and sets up connection attempts to all the provisioned addresseson the subscriber's list. onConnectionConnected()—Handles theCONNECTION_CONNECTED event, which indicates that one of the connectionattempts resulted in a successful connection. The logic then completesthe connection process for that attempt and releases all other attempts.onConnectionFailed()—Handles the CONNECTION_FAILED event, whichindicates that one of the connection attempts resulted in a busyconnection. The logic then terminates all the connections and forwardsthe call to the voice mail address.

This service example does not need any service level data. However, eachsubscriber needs to provide a list of phone numbers to find and adefault voicemail number. The data model for the service will contain: asubscriber scope PhoneList containing a list of phone numbers and asubscriber scope voicemail phone number.

The service descriptor definition may include events, event handlers,data model, and the other information in the JSDL and TSDL descriptors.The JSDL part of the service descriptor definition may include serviceinformation, service classes and event entries. The service informationpart of JSDL contains information to uniquely identify the service likename, vendor, version, and description. For the FindMe service, weprovide the following information:

-   Service Name: findme-   Service Vendor: TrueTel Communications-   Service Version: 1.0-   Service Description: For incoming calls “Finds” the Subscriber at    one of the multiple configured addresses.    An XML fragment that corresponds to this information follows:

<service-info> <description> For incoming calls Finds the Subscriber atone of the mul- tiple configured addresses.</description><service-name>findme</service-name> <service-vendor>TrueTelCommunications</service-vendor> <service-version>1.0</service-version> .. .This fragment and others that follow are part of the overall JSDL file“JSDL.xml” that is included in the CDRom appendix.

The service classes part of the JSDL contains information about variousservice classes that the service developer provides or expects SLEE togenerate so that they can be used in the code. For the FindMe service,we provide the following information:

-   Service Class: com.truetel.svc.findme.FindMeSbb-   Service Profile: com.truetel.svc.findme.FindmeSbbProfileData-   Subscriber Profile:    com.truetel.svc.findme.FindmeSubscriberProfileData    An XML fragment that corresponds to this information follows:

<service-classes> <service-class><abstract-class-name>com.truetel.svc.findme.FindMeSbb</abstract-class-name> </service-class> <service-profile><profile-ro-class>com.truetel.svc.findme.FindmeSbbProfileData</profile-ro-class> <jmx-manager>null/jmx-manager> </service-profile><subscriber-profile> <profile-ro-class>com.truetel.svc.findme.FindmeSubscriberProfileData</profile-ro-class><jmx-manager>null</jmx-manager> </subscriber-profile> </service-classes>

The event entries part of the JSDL contains information about variousevents that the service handles or generates. For this service, wedefine the details of the three events identified in the servicedefinition. CONNECTION ALERTING event is identified as Initial and theall three events are of “listening” type for the service. We also definethe priority although is it largely irrelevant for a single servicecase. We also define the respective event handlers to be defined in theservice class FindMeSbb to handle these events. For the CONNECTIONALERTING event:

-   Type: Listen-   Priority: 3-   Initial: True-   Event ID:-   jain.application.services.jcp.JcpConnectionEvent.CONNECTION_ALERTING-   Event Class: jain.application.services.jcc.JcpConnectionEvent-   Event Handler: onConnectionAlerting()    For the CONNECTION CONNECTED event:-   Type: Listen-   Priority: 2-   Initial: False-   Event ID:-   jain.application.services.jcp.JcpConnectionEvent.CONNECTION_CONNECTED-   Event Class: jain.application.services.jcc.JcpConnectionEvent-   Event Handler: onConnectionConnected()    For the CONNECTION FAILED Event:-   Type: Listen-   Priority: 1-   Initial: False-   Event ID:-   jain.application.services.jcp.JcpConnectionEvent.CONNECTION_FAILED-   Event Class: jain.application.services.jcc.JcpConnectionEvent-   Event Handler: onConnectionFailed()    An XML fragment that corresponds to this information follows:

<event-entry type=“Listen” custom=“true” priority=“3” initial=“true”><event-id>jain.application.services.jcp.JcpConnectionEvent.CONNECTION_ALERTING</event-id><event-class>jain.application.services.jcc.JccConnectionEvent</event-class><event-handler>onConnectionAlerting</event-handler> </event-entry><event-entry type=“Listen” custom=“true” priority=“2” initial=“false”><event-id>jain.application.services.jcp.JcpConnectionEvent.CONNECTION_CONNECTED</event-id><event-class>jain.application.services.jcc.JccConnectionEvent</event-class><event-handler>onConnectionConnected</event-handler> </event-entry><event-entry type=“Listen” custom=“true” priority=“1” initial=“false”><event-id>jain.application.services.jcp.JcpConnectionEvent.CONNECTION_FAILED</event-id><event-class>jain.application.servicesjcc.JccConnectionEvent</event-class><event-handler>onConnectionFailed</event-handler> </event-entry>

The service information part of TSDL contains some of the sameinformation on the service as the JSDL. In addition, it also containsthe i18nfile for internationalization of various strings for display inthe provisioning interfaces. For the FindMe service, we provide thefollowing information:

-   Service Name: findme-   Service Version: 1.0-   i18nfile: com.truetel.svc.findme.properties.FindMeI18N    An XML fragment that corresponds to this information follows:

<TSDL xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:noNamespaceSchemaLocation=“TSDL.xsd” svcName=“findme”svcVersion=“1.0” i18nfile=“com.truetel.svc.findme.properties.FindMeI18N” createDate=“2001-07-05”> . . . </TSDL>

The TSDL version of the service data description, set forth below, canbe used by the service developer to specify aspects of the service. Theexample below includes a subscriber scope service table called AddrList,with attributes AddrId and AddrStr; a subscriber scope service propertycalled VoiceMail, with attribute VoiceMailAddress; and a service scopeservice property called TimeOut, with attribute Duration. Subscriberscope means that the data in the table is on a per subscriber basis andthe subscriber is implicitly part of the key. AddrList table containsthe list of phone numbers to “Find” the subscriber when an incoming callarrives. This simple table contains service attribute called AddrStr,which is of the type “String” with a maximum length of 10. A serviceproperty is service or subscriber scope data that contains one or moreattributes. These attributes have only one value in the service orsubscriber scope. For our FindMe service, we define a subscriber scopeservice property called VoiceMail containing a single service attributecalled voiceMailAddress, which is of the type “string”.

<?xml version=“1.0” encoding=“UTF-8”?> <TSDLxmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:noNamespaceSchemaLocation=“TSDL.xsd” svcName=“FindMe”svcVersion=“1.0”> <SvcTable admAccessMode=“none” scope=“subscriber”subscriberAccessMode=“none” svcAccessMode=“none”svcTableName=“AddrList”> <SvcAttr admAccessMode=“rw” isRequired=“true”isSvcChangeable=“false” subscriberAccessMode=“none” svcAttrName=“AddrId”svcEnumName=“” type=“Short”/> <SvcAttr admAccessMode=“rw”isRequired=“true” isSvcChangeable=“false” maxLength=“10”subscriberAccessMode= “none”svcAttrName=“AddrStr” svcEnumName=“”type=“String”/> <SvcTableKey> <AttrName>AddrId</AttrName> </SvcTableKey></SvcTable> <SvcProperty scope=“subscriber” svcPropertyName=“VoiceMail”><SvcAttr admAccessMode=“rw” isRequired=“true” isSvcChangeable=“false”subscriberAccessMode=“none” svcAttrName=“VoiceMailAddress”svcEnumName=“” type=“String”/> </SvcProperty>  <SvcPropertyscope=“svc-global” svcPropertyName=“TimeOut”> <SvcAttradmAccessMode=“none” isRequired=“true” isSvcChangeable=“false”subscriberAccessMode=“none” svcAttrName=“Duration” svcEnumName=“”type=“Short”/> </SvcProperty> </TSDL>This XML fragment is part of the file TSDL.xml in the CDRom appendix.

In the fragment above, the use of data types is illustrated. Supporteddata types include Enum, Integer, Long, Short, String, Boolean,Timestamp, DigitString and FileName. Not all of these data types will berequired for every application. Additional data types can readily besupported by extension of the TSDL schema. The following table shows youhow SLEE maps the service attribute type into internal Database types,and the Java class that it returns when accessed using the accessormethods.

type Database Type Java Class Integer NUMBER (10) Integer Long NUMBER(20) Long Short NUMBER (5) Short Enum NUMBER (3) SvcEnum Value classString VARCHAR2 String Timestamp DATE Timestamp Boolean NUMBER (1)Boolean DigitString VARCHAR2 String FileName VARCHAR2 StringFor the service attributes of type string, maxLength should bespecified, or maxLength may default to the maximum allowed length of thestring on the system. For the service attributes of type Enum, thesvcEnumName should be specified to identify the Enum that is definedelsewhere in the TSDL. A required attribute is specified by setting theisRequired attribute of the Service Attribute to true. The default valueof isRequired is false.Default value of an attribute can be specified in the defaultValueattribute. The attributes admAccessMode and subscriberAccessMode specifythe access mode of the attribute by the Administrator and the Subscriberrespectively. The following lists the various permitted modes. Note thatchange access allows modification of existing attributes but does notallow creating them, whereas write provides both. Other accesses includenone, which provides no access, ro for read only access, rc read andcreate access, and rw for read, create, and write access.

TSDL also may contain information on service implementation extensionssupported by the SLEE platform. For the FindMe service, we provide thefollowing data: globalSIMode and subscriberSIMode—these control theservice convergence, and we set them to none and manyPerSubscriber.svcEventRouting—this provides the class implementing callback functionsto identify subscriber address from the incoming events. We set this tocom.truetel.svc.findme. AddrType—this provides the type of subscriberaddresses that this service can serve. For Findme this will be atelephone number, so we set this to PhoneNo.

Programming objects also can be generated by the SLEE, includingprogramming objects for the public interface to the data. These objectscan be used in the service code to access the data from the underlyingplatform database. For example, for the subscriber scope service table“AddrList”:

public class AddrList { AddrList (Short AddrId, String subscriberName);public Short getAddrId( ); public void setAddrId(Short AddrId); publicString getAddrStr( ); public void setAddrStr(String AddrStr); publicvoid revert( ); public void retrieve( ); public void commit( ); }For the subscriber scope service property “VoiceMail”:

public class VoiceMail{ VoiceMailProperty (String subscriberName);public String getVoiceMailAddress( ); public voidsetVoiceMailAddress(String VoiceMailAddress); public void revert( );public void retreive( ); public void commit( ); }For service scope service property “TimeOut”:

public class TimeOut{ TimeOutProperty ( ); public Short getDuration( );public void setDuration(Short Duration); public void revert( ); publicvoid retreive( ); public void commit( ); }These object classes support the service developer's efforts to create aservice. The system also may generate wrapper objects for these dataobjects to group all the service scope data and subscriber scope data.

The following illustrates database tables, columns and column types, andkeys that can be automatically created in the platform database for theFindMe service. This is the physical data model corresponding to thespecification. The SERVICEOID and SUBSCRIBEROID are platformsrepresentation of the service and subscriber data that the scope of thedata is related to. For the service scope service propertyFINDME_TIMEOUT:

Column Name Key? Type SERVICEOID Yes NUMBER(20) DURATION NUMBER(5)For the subscriber scope service property FINDME_VOICEMAIL:

Column Name Key? Type SUBSCRIBEROID Yes NUMBER(20) VOICEMAILADDRESSVARCHAR2(32)For the subscriber scope service table FINDME_ADDRLIST:

Column Name Key? Type SUBSCRIBEROID Yes NUMBER(20) ADDRID Yes NUMBER(5)ADDRSTR VARCHAR2(10)

The system also may generate provisioning interfaces, such as HTML pagesfor browsers. FIGS. 2A and 2B show user interfaces that SLEE cangenerate for the subscriber scope data access for the FindMe service.The list column 200 indicates the properties and tables availablethrough the interface. FIG. 2A provides access to the propertyVoiceMailAddress 201, which may be edited by selecting-the edit button202. In some interfaces, the edit button will invoke a further interfaceorganized for entry of detailed information. FIG. 2B provides access tothe table AddrList 210 and the attributes AddrId and AddrStr. Thenumbers at which the subscriber should be called are entered as AddrStrattributes. The interfaces in these figures are automatically generatedfrom the service description and can be accessed by the users through aweb browser. Similar interfaces may be generated for the service scopedata as well, when a service requires service scope data. SLEE maygenerate interfaces in the WML and VXML formats as well, for thesubscriber scope data.

A service creation environment supports (SCE) collection of data,translation of the data into a machine readable specification such asTSDL and automatic generation of useful software components to supportservice generation. Much of the behavior of the SCE can be recognizedfrom its graphical user interface, aspects of which are depicted inFIGS. 3 through 27.

FIG. 3 is a tree that organizes information collected through the userinterface. Information pertaining to a service may be categorized asJSDL information, TSDL information, I18N information, and packagingdata. The hierarchical tree view shown in FIG. 3 supports thisorganization. A service node 301 acts as a root node and provides theviews for manipulating service details as per JSDL and TSDLspecifications. A Service-View 310 and a Subscriber-View 320 containdatabase related information as specified by TSDL. The differencebetween these two views is that the Service-View maintains the elementsof service global scope whereas the Subscriber-View maintains thesubscriber scope elements. In this example, the subscriber view includesservice tables person 321 and phone 322. The I18N view 330 allows userto create and specify the service attributes according to differentlocales. The Packaging View 340 keeps track of all the classes, EJBs andJars related to the service.

FIG. 4 is a graphical user interface that collects service informationcategorized as basic information 410, other information 420 and adescription 430. This interface is accessed via the info tab 401. Inparticular, this embodiment of the user interface collects Name, whichis a service name. Though, JSDL does not enforce a name length, TSDLrestricts name to not more than 10 characters. Vendor is the name of thevendor of the service, which may be the service developer. Versionidentifies the current version of the service. Create Date specifies theservice creation date. In this example, the date is in YYYY-MM-DDformat. This format may be configurable. To change date, click Calendarand specify the date. Icon File Name is a path to a service icon thatwill be used for showing the service. This may be an absolute path ormay be relative to a base location entered elsewhere. Session Timeout isthe total time interval, in milliseconds, to wait for a response fromthe service logic after it hands over the event to SLEE. Max ExceptionsAllowed is the maximum number of exceptions to be handled by SLEE forthe current service. Description is a text description for the service.Among these fields, Name, Version, Vendor should be mandatory. Fieldssuch as, Create Date and Icon File Name are part of TSDL data, which maybe optional.

FIG. 5 is a graphical user interface that collects identifiers ofservice classes 510. This interface is accessed via the classes tab 502.In particular, this embodiment of the user interface presents classes511 that are specified by JSDL or by TSDL or typically used by servicedevelopers and collects class names 512 specified by the user.Alternatively, this data can be imported from elsewhere and edited usingthe interface. In addition to the classes shown in the figure, thisinterface also may support the classes Service Event Routing Class,Service Provisioning Class, Service Profile Data Class and SubscriberProfile Data Class. It further may support any of the classes identifiedin the CDRom appendix. Service Logic Class is the abstract class namefor the service logic. Activity Spec Class is the interface for theactivity context of the service. Service Deployment Class is thedeployment class for the service. Service Management Class is theservice management class. Service Subscription Class is the servicesubscription class. Service Event Routing Class and Service ProvisioningClass are the service extension implementation classes used forspecifying event routing and service provisioning respectively. ServiceProfile Data Class and Subscriber Profile Data Class are read onlyprofile classes for service and subscriber respectively. Class namesprovided should be fully qualified names. The Action button 513 offersthe user choices of editing the class, browsing it, or generating codefor the class. Edit opens a Java source for the corresponding class inan editor. Browse is used to specify a class name from a list or tree. Aselected class file entry will be parsed to generate a fully qualifiedname. Generate will generate the specified class in a predetermined orselected folder.

FIG. 6 is a graphical user interface that collects event information610, including event ids 611, event classes 612 and detailed information620. This interface is accessed via the events tab 603. The edit button613 of this interface is linked to an additional detailed entry screenor wizard shown in FIG. 7.

The event details 720 collected in FIG. 7 include Event id 711, which isa static constant defined in Event Class. For example, from“jain.application.services.jcc. JccConnectionEvent” event class, theEvent id can be “CONNECTION_ALERTING”. Event Class 712 is a fullyqualified Event Class Name. Event Handler 721 is a method defined inevent listener that handles the event when it is invoked. Id ReturnedType 722 provides a pick list of possible values that can be accepted asEvent Types. Event Type 723 is either Listen or Fire. Priority 726 isthe priority of the service for the event, for instance in the range 0to 255, inclusive. Proc 727 provides a pick list for specifying thatevent processing is either to continue or be suspended. If the event issuspended, the dispatcher will only pass the event to one service at atime. Description 728 is a text description for the event. The check boxCustom 724 is checked when the event is user defined. The check boxInitial 725 is checked when association of the event with an existingactivity will be enabled. Among these entries, Event id, Event Class,Priority should be mandatory information. At least one event is requiredin a service. Click the event shown in the table to view its details. Toadd an event, click Add.

FIG. 8 is a graphical user interface that allows identification of usageinformation 810 and resource information 820 that the service shouldcollect during operation. This interface is accessed via theusage/resource tab 804. In particular, this embodiment of the userinterface allows identification of one or more parameter names 811 anddescriptions of the parameters 812 and identification of one or moreresource names 821 and resource types 822. For usage parameters, ParamName is a name of the parameter, which should match the string that theservice passes when it invokes methods that track usage. Description isa text description for the parameter. Resource Information contains adeclaration of a service's reference to an external resource. ResourceName is a name of a resource manager connection-factory reference.Resource Type is a type of resource data source. The type may bespecified by the Java interface or class expected to be implemented bythe data source. Description is a text description for the resource.Click Edit to specify/view description.

FIG. 9 is a graphical user interface that collects JNDI EnvironmentEntries 910, including entry names 911, entry types 912 and detailedinformation 920. This interface is accessed via the EnvEntry tab 905.Env Entry Name is a name of an application's environment entry. EnvEntry Type is a fully qualified Java type of the environment entry valuethat is expected by the application code. Description is a textdescription for the environment-entry. Value is the value of anapplication's environment-entry. Much of the information is optionallycollected through the interfaces of FIGS. 4 through 9 is called for by aversion of the JAIN SLEE standard.

TSDL related information optionally may be specified using theinterfaces in FIGS. 10 through 26. FIG. 10 is a graphical user interfacethat collects web application related data 1010, including basicinformation 1010 and entry details 1020. This interface is accessed viathe WebApp tab 1006. Resource Name is a name of the resource the servicerefers to. Service Web App Name is a name of the service that will bedisplayed in the web application. The user can also specify entrydetails 1020 including HTML Entry, Sub WML Entry, Sub HTML Entry, andSub VXML Entry, as specified in the TSDL schema. An entry should have acorresponding Resource Name and Service Web App Name.

FIG. 11 is a graphical user interface for specifying enumerations 1110that allow a service developer to specify the possible values of avariable with meaningful symbolic names. It is accessed via the Enum tab1107. A named enumerator 1111 has a list of enumerated names 1112 andvalues 1113 corresponding to the names.

FIG. 12 is a graphical user interface that collects service mode 1210and adds lookup 1220 information. It is accessed via the ext tab 1208.SCE allows specifying the Global Service Instance (GSI) mode 1211 andSubscriber Service Instance (SSI) mode 1212 information used forhandling incoming events. Moreover, associated subscriber informationcan also be specified by Address Lookup 1220 mechanism. SubscriberService Instance Mode 1211 specifies the mode of controlling thesubscriber scope of service logic. The supported modes aremanyPerSubscriber, onePerSubscriber, manyPerAddress, onePerAddress, andnone. Global Service Instance Mode 1212 specifies the mode ofcontrolling the global scope of service logic. The supported modes aremanyPerService, onePerService, manyPerAddress, onePerAddress, and none.Gsi Address Lookup Table 1221 and Address Lookup Table 1222 are servicetables used for respective address lookups. To specify this, click Editof corresponding field. Address types 1230 enumerate supported addresstypes, in this example identified by the originating network protocol.

FIG. 13 is a graphical user interface to a Gsi Address lookup table.Select the required table from the drop down list 1321. Gsi AddressLookup attribute, which is a unique key attribute or indexed attributeof “global-svc” scope, present in Gsi Address Lookup Table. To specifythis attribute, click Edit, and FIGS. 14 and 15 become accessible. InFIG. 14, Address Lookup attribute 1422 is a unique key attribute orindexed attribute of “global-svc” scope, present in Address LookupTable. Addr Types 1530 in FIG. 15 are the elements that define the typesof subscriber addresses that the service supports. Those of skill in theart will recognize that a pick list or other control style can besubstituted for the radio buttons illustrated. New Addr Types can beadded.

The hierarchical tree of FIG. 3 provides access to interfaces foridentification of properties, tables, beans and file types. Both of theservice and subscriber views will maintain the service properties,tables, beans (both Java and Enterprise Java Beans) and file tables oftheir respective scope; service view maintains the “svc-global” scopewhereas subscriber view maintains “subscriber” scope. These four simpleinterfaces are not reproduced, because they include a name, a set ofaction buttons, and, for beans, identification of a bean as a Java Beanor EJB. More elaborate interfaces defining easily named entities appearas FIGS. 16 through 26.

FIG. 16 is a graphical user interface for specification of serviceproperties. Property Name 1610 is a name of a service property (maximum14 characters). As described above, a service property contains zero ormore attributes 1620, foreign keys 1630 and indexes 1640. For theseelements, there are corresponding action buttons.

FIG. 17 is a graphical user interface for adding an index, to enhancesystem performance. Index Name 1710 is a name of a service index (max 14characters). Attribute Name(s) 1720 are one or more attributes to beindexed by this index. The index present in property will have uniquescope as “svc-global”.

FIGS. 18 and 19 are two out of three steps for creating a foreign key.Omitted is the simple interface for naming the foreign key andassociating it with a foreign table. Foreign key can be either mapped toone or more key(s) or to an index to a foreign table. FIG. 18 allows auser to select a key or an index to the foreign table 1820 to associatewith the named foreign key 1810. In the next step for a named foreignkey 1910, depicted in FIG. 19, the user specifies the mapping betweenthe attributes of the property 1920 and the attributes of the foreigntable 1930. Map the current property attribute 1920 by selecting theforeign attribute from drop down list 1930.

FIG. 20 is a graphical interface for defining a service table, includingdefining basic details 2010, mode details 2020, attributes 2030, keyattributes 2040, indexes 2050 and foreign keys 2060. Name is a name ofservice table (maximum 14 characters). Container Table Name is the nameof the container table, if this table is nested. ADM Access Mode 2021,Subscriber Access Mode 2022 and Access Mode 2023 specify the accessgiven to administrators, subscribers and users for this table. Theaccess modes include none, ro—read only, ru—read, and rw—read write. Aservice table should contain at least one key attribute 2040. Adding ofa service attribute 2030, index 2050 and foreign key 2060 to a table issame as for a service property, except table index can have both“svc-global” and “subscriber” unique scopes.

FIG. 21 is a graphical interface for defining attribute details,including its name 2110, properties 2120, mode details 2130, GUIproperties 2140 and static validation rules 2150. Attribute Name 2110 isa name of the service attribute. ADM Access Mode and Subscriber AccessMode are used to define access rights for administrators and subscribersto this attribute. Supported rights may include rw—read write, ro—readonly, rc—read create or none. There are three properties for GUI 2140for this attribute. The Auto Generated will specify whether thisattribute is auto generated by service, subscriber or none. Thedeveloper can also specify whether the attribute is searchable andwhether to show the attribute in a grid. In properties 2120, type is theattribute type from the defined types. Enum Name is the name of theenumerator. This corresponds to the Enum from Enum Tab. This can bespecified only if the Type is Enum of FIG. 11. Default Value is anoptional default value for the attribute. It can be a constant, literalor an Enum item. It can be extended to a value calculated from otherfields. File Table Name is the file table name when the type isFileName. Max Length for Types String, FileName or DigitString indicatesthe number of characters the value of this attribute can be. A usefuldefault for these types is 20. For other types it does not matter.Required may be checked or not. Changeable may be if checked to enablethe attribute to be modified by the system. Validation Rule Type 2150 isa rule that can be applied to check the validity of the attribute'svalue. Three supported types of rules include length validation, rangevalidation and regex validation, to check for regular expressions. Arule is given a Rule Name 2152. Then based on the type of rule, the ruleis defined 2153. In this example length validation has minimum andmaximum length values. To add a static validation rule, click Add.Supporting interfaces depicted in FIGS. 22-23 become accessible.

In FIG. 22, rule name 2252 is a user defined name for the rule. RuleType 2260 is a control for selecting a supported type of rule. FIG. 23corresponds to the length validation rule 2153, allowing entry of therule name 2352, minimum length 2353A and maximum length 2353B.

FIGS. 24-25 are interfaces for entry and mapping of foreign keys. Thedetailed information for a foreign key includes properties 2410 andattribute name 2420. Name is a name of a foreign key. Foreign Table Nameis a name of foreign table. Foreign Index Name is used when a foreignkey is associated with the index of the foreign table to indicate thename of the foreign index. Cascade Delete Allowed may be checked or not.Attr Names 2420 is a list that contains the mapping of the current tableor property's attribute (Attr Name) with the foreign table's attribute(Foreign Table Attr). Clicking on Modify Attr Names can change theexisting mapping of attributes.

FIG. 25 is a graphical interface for a user to specify index details.The index details include index properties 2510 and attribute names2520. Name is a name of service index (Max 14 characters). DB Name is adatabase name for the index. Unique is checked, when the index is uniquewithin the table. Unique Scope is a pick list for selection of the scopeof the index. For the Index in Service-View, i.e. “svc-global”, shouldhave “svc-global” scope. Attr Names 2520 specifies the attributesindexed by the index. User can add or remove attributes to the list.

Not depicted in the figures are graphical interfaces for definingoperations, file table names, an I18N file, and a packaging view.

FIG. 26 is a pull-down menu that allows a developer to invoke aspects ofautomatic code generation. The developer can select generation of allavailable components or can select specific components. In thisillustration, the specific components listed are service logic class2611, service deployment class 2612, service management class 2613,service subscription class 2614, service/subscriber profile data class2615, and data classes 2616. This logic automates the common codegeneration thereby eliminating the error prone manual coding.

FIG. 27 illustrates the converged network that has been referred toabove, in the context of a converged service for personal informationmanagement 2701. In the converged network, data flows through thecommunications network 2720 from a variety of sources. Communicationevents from any of these sources can generically be referred to as acall, regardless of whether a voice or data message is involved.Adapters in a service logic execution environment 2712 receive callsfrom these heterogeneous networks. The personal information managementservice 2701 operates in the service logic execution environment 2712.It accesses a service data source 2711 and also may access a voiceresource 2713. A wide variety of sources are illustrated in the figure.An Internet application content server 2721, such as a Yahoo! server maybe in communication with the SLEE 2712. A presence server 2722 orlocation server 2726 also may be in communication with the SLEE 2712.Voice networks also may be in communication with the SLEE 2712, such asvoice networks supported by a wired PSIN switch 2723, a wireless MSCswitch 2724 or voice over IP Softswitch 2725. The convergence of voicenetworks allows subscribers using a conventional handset 2731, awireless handset 2732 or PC-based voice equipment 2733 to access thepersonal information management service 2701. Aspects of the presentinvention support development and deployment of advanced services suchas a personal information management service.

From the preceding description, it will be apparent to those of skill inthe art that a wide variety of systems and methods can be constructedfrom aspects and components of the present invention. One embodiment isa telecommunications system including a service logic executionenvironment. The SLEE supports a plurality of services and complies witha telecommunications computing standard, such as JAIN SLEE. The systemfurther includes a first service operable on the SLEE utilizing servicedata corresponding to a machine readable specification. The machinereadable specification includes definitions of data attributes havingtypes and optionally being required, having a default value and havingvalid values. The definitions further include tables of data attributesadaptable to store configuration data for the service and validationrules. The validation rules may apply to individual attributes, maycompare attributes in a single row or record, or may compare dataattributes among rows or records. Additional aspects of this embodimentinclude defining data attributes as automatically generated. Thedefinitions further may include identification of one or more methodsthat can be invoked by the service to apply additional validation rules.A variation on this embodiment is a machine readable specification forservice data used by a service operable in the SLEE. This variationincludes the aspects and options of the first embodiment, withoutincluding the SLEE itself.

A second embodiment is a data interface generator, generating aninterface to data used by a service sharing a SLEE. The data interfacegenerator includes first logic operable on a computer system. The firstlogic acts upon or is responsive to a machine readable specification.The specification includes aspects and options of the machine readablespecification described above. The first logic is adapted to utilizeinformation in the specification to generate a data interface.Generating the data interface may include generating a data model thatmaps data attributes, types and tables to database fields types andtables. In may include generating second logic that accesses andpersists data corresponding to the data model. It further may includegenerating third logic that implements the validation rules of thespecification. A further component of the first logic may be adapted togenerating a data base definition that implements the data model. Thisdata base definition may be run on a database system to generate aphysical database. Another component of the first logic may be adaptedto generate a provisioning interface that is accessible through anetwork and facilitates user entry of values corresponding to at leastsome of the data attributes. The first logic may validate thespecification against a data schema.

Another embodiment is a graphical interface including a plurality ofuser interfaces to collect information corresponding to one or moremachine readable specifications. The user interfaces may be organized tocollect information including a service name, one or more attributedefinitions and service data definitions, including service propertiesand service tables. This embodiment further may include collection ofclass names of objects implementing service interfaces. It further mayinclude collection of specifications for communications events to whichthe service will respond. If further may identify usage parameters thatthe service compiles during operation. The user interfaces may furtherbe organized to collect validation rules and/or methods that can beinvoked to apply external validation. Other user interfaces may beprovided to collect enumerator data type definitions, includingenumeration values.

A combined embodiment includes a graphical interface, such as the onedescribed above, and logic adapted to generate useful softwarecomponents. The useful software components may include data model thatmaps data attributes, data types and tables to database fields, datatypes and tables. It may include generating logic to access and persistdata corresponding to the data model. It also, or alternatively, mayinclude generating logic that implements the validation rules.Optionally, the data interface generator logic may be adapted togenerate a data base definition that a database system can use togenerate a physical database. In general, these embodiments may utilizeone or more machine readable specifications, one of which may becompliant with a version of a telecommunications standard, such as JAINSLEE, and the other supplementing the standard.

While the present invention is disclosed by reference to the preferredembodiment and example detailed above, it is understood that theseexamples are intended in an illustrative rather than in a limitingsense. Computer-assisted processing is implicated in the describedembodiments. Accordingly, the present invention may be embodied inmethods for computer-assisted processing, systems including logic tospecify and generate data interfaces and structures, media impressedwith logic to specify and generate data interfaces and structures, datastreams impressed with logic to specify and generate data interfaces andstructures, or computer-accessible services that specify and generatedata interfaces and structures. It is contemplated that modificationsand combinations will readily occur to those skilled in the art, whichmodifications and combinations will be within the spirit of theinvention and the scope of the following claims.

1. A telecommunications system development tool for specifying servicesto be deployed on a shared device, a device including: a service logicexecution environment (“SLEE”) that is running on a device, supporting aplurality of services, and that is compliant with a telecommunicationscomputing standard for SLEEs; a first service operating in the servicelogic execution environment utilizing service data corresponding to acomputer-readable specification, the computer-readable specificationincluding definitions of: data attributes having types and optionallybeing required, having a default value and having valid values, thedefinition of the data attributes being used to automatically generatethe data attributes that store the service data; tables of dataattributes adaptable to store configuration data for the service; andvalidation rules for data attributes, among data attributes in rows ofthe tables, among data attributes across the rows in the tables thevalidation rules being used to validate the automatically generated dataattributes.
 2. The device of claim 1, wherein the definitions furtherinclude identification of one or more methods that can be invoked by theservice to apply additional validation rules.
 3. A computer-readablestorage medium having instructions for specifying service data used by aservice, the service sharing a service logic execution environment(“SLEE”) that is compliant with a telecommunications computing standardfor SLEEs, the service being responsive to events generated by handlingcalls, the computer-readable specification accessible in memory of theservice logic execution environment including definitions of: dataattributes having types and optionally being required, having a defaultvalue and having valid values, the definition of the data attributesbeing used to automatically generate the data attributes that store theservice data; tables of data attributes adaptable to store configurationdata for the service; and validation rules for data attributes, definingvalidation relationships among data attributes in particular rows of thetables and among data attributes across different rows in the tables,the validation rules being used to validate the automatically generateddata attributes.
 4. The storage medium of claim 3, wherein thedefinitions further include identification of one or more methods thatcan be invoked by the service to apply additional validation rules.
 5. Adata interface generator development tool for specifying and generatingcode that implements a service to be deployed on a shared device, thedata interface generator including: primary logic operating on acomputer system generating an interface to data used by a servicesharing a service logic execution environment that is compliant with atelecommunications computing standard with a plurality of otherservices, the service and other services being responsive to eventsgenerated by handling calls, the primary logic including: first logicacting upon a computer-readable specification that defines the interfaceto the data used by the service, the specification including definitionsof: data attributes having types and optionally being required, having adefault value and having valid values; tables of data attributesadaptable to store configuration data for the service; validation rulesfor data attributes, defining validation relationships among dataattributes in particular rows of the tables and among data attributesacross different rows in the tables; wherein the first logic is adaptedto automatically generate a data interface based on the configurationdata, including: generating a data model that maps data attributes,types and tables to database fields, types and tables; generating secondlogic that accesses and persists data corresponding to the data model;and generating third logic that implements the validation rules, thevalidation rules being used to validate the automatically generated dataattributes.
 6. The data interface generator of claim 5, wherein thedefinitions further include identification of one or more methods thatcan be invoked by the service to apply additional validation rules. 7.The data interface generator of claim 5, wherein the first logic isfurther adapted to generate a data base definition that implements thedata model.
 8. The interface generator of claim 5, wherein the firstlogic is further adapted to generate a provisioning interface that isaccessible through a network and facilitates user entry of valuescorresponding to at least some of the data attributes.
 9. The datainterface generator of claim 5, wherein the first logic is furtheradapted to validate the specification against a data schema.
 10. Thedata interface generator of claim 5, further including the computersystem.
 11. A graphical computer interface to a development tool forspecifying services to be deployed on a shared device, a deviceincluding: a plurality of computer-implemented user interfaces adaptedto collect information corresponding to one or more computer-readablespecifications of a service interface for a service sharing a servicelogic execution environment with a plurality of other services, theservice and other services being responsive to events involved inhandling calls, the user interfaces organized to collect informationincluding: a service name; one or more data attribute definitions, thedata attributed defined as having types and optionally being required,being automatically generated, having a default value and having validvalues; service data definitions, including one or more serviceproperties and service tables, wherein the service properties includedata attributes and wherein the service table includes tables of dataattributes; validation rules applicable among data attributes in rows ofthe tables and among data attributes across the rows in the tables, thevalidation rules being used to validate the automatically generated dataattributes; class names of objects implementing aspects of the serviceinterface; communications events to which the service will respond;usage parameters that the service compiles during event handling; andenumerator data type definitions and enumerator item values that can beused by the data attributes.
 12. The device of claim 11, wherein theuser interfaces are organized to further collect identifiers of methodsthat can be invoked by the service to apply additional validation rules.13. A generator of specifications stored on a computer-readable storagemedium, a device including; a plurality of computer-implemented userinterfaces running on a device and adapted to collect informationcorresponding to one or more computer-readable specifications of aservice interface for a service sharing a service logic executionenvironment with a plurality of other services, the service and otherservices being responsive to events involved in handling calls, the userinterfaces organized to collect: a service name; one or more dataattribute definitions, the data attributed defined as having types andoptionally being reguired, being automatically generated, having adefault value and having valid values; service data definitions,including one or more service properties and service tables, wherein theservice properties include data attributes and wherein the service tableincludes tables of data attributes and first logic operable on acomputer system to generate a data interface, the first logic beingadapted to: generate a data model that maps the data attributes, typesand tables to database fields, types and tables; generate second logicthat accesses and persists data corresponding to the data model; andgenerate third logic that implements the validation rules, thevalidation rules being used to validate the automatically generated dataattributes.
 14. The device of claim 13, wherein the first logic isfurther adapted to generate a data base definition that implements thedata model.